SuperHack/SuperHack CD.bin/MISC/IHHD-04.ZIP/IHHD-04.TXT

Text File | 1993-08-13 | 49KB | 1,334 lines

-------------------------------------------------------------------------------
               Internet Head-To-Head Feed #04 - as of 09-Aug-93
-------------------------------------------------------------------------------
Date: Wed, 30 Jun 93 09:04:29 CDT
From: I'll see you on the dark side of the moon <[e-mail]>
To: Multiple recipients of list <[e-mail]>
Subject: Things...

hi...

I was sitting on IRC one day, bored, and had always wanted to play a modem
game over the internet...So I went to work, and in 15 minutes I whipped up
my little socket program that just opens a raw connection (tcp) between 2
hosts.

I have also written a VERY simple IRCii script to enable some modem games
that delimit packets with an CR to be playable even over IRC! I have
played perfect general tvis way as well, works great

 I started asking people if they wanted to play a game...finally found
somebody willing to play Perfect General. So we used my connection program
and off we went playing. It was great, we ran into 0 problems and it
worked great.

I own an Amiga2000 and a USR Dual standard...local v32 9600 baud dialup
was used at UMD.. I am also wondering why every mention here seems to be
from PC owners...its all COM port this Falcon 3.0 that, MS-DOS this and
that...i'm letting you know you can play games over the net with any
personal computer...

I was going to stick a Makefile on my program and write some docs, and
stick it up for ftp at various places until I found this ihhd deal. I have
mixed feelings...I'm not sure to be angry with it because someone else
already had my idea, or happy to find extra players :) I have read through
the archive and looked at the source, and it is very similar to mine.

I have been wondering why there are so many tests going on...it really
isn't all that necessary...You whip up the program...test ping times and
go. I am seeing people posting ping times in the thousands...These ping
times are just fine for non-action games, but will never ever work on
action games. From my experiences, any ping times more than 100ms you can
forget it for stuff like Falcon and Firepower etc etc. It just can't work
because the delay is far too great. Another good thing to look for is the
way the game sends data...look at your send data and receive data lights
on your modem. If they only flash once in a while when you do moves etc,
it may work...but if it looks like it sends a packet every second or so,
you will need less than 100ms ping times.

The bottom line is this...action games such as Falcon and firepower will
most probably never work...there is a chance of them working with decent
ping times such as less than 75-100ms...games like perfect general work
flawlessly...remember, these modem interfaces were designed for ZERO lag
time..nothing..instantaneous connections.

Now...anybody want to play perfect general, leave me some mail... :)

 ---
[e-mail]

-------------------------------------

Date: Wed, 30 Jun 93 14:37:07 CDT
From: [e-mail] (michael sanches)
To: Multiple recipients of list <[e-mail]>
Subject: Conyinuous Data Games

Hi Kreator, et al,

     As one who likes to play games, but knows little about
programming, I say that the more people experimenting on this the
better.
     I am waiting for the new Perfect General to come out before I
purchase a copy. When it comes out, I look forward to playing it on
the net. Maybe we can have a Perfect General Ladder and Tourney. By
the time it comes out, the Axis and Allies Tourney I am running on the
net will be winding down. Maybe that will be a good time to start a
TPG tourney.
     Right now, I am trying to get Command HQ to work over the net.
Any help you could contribute, Kreator, would be appreciated. We have
got it to work at about 92% speed over PC Pursuit. We have a
NETWORK.OVL file that breaks the cotinuous stream of data into packets.
     So, instead of relying total on developing a perfect dialer
program, we are also modifying the game software (sort of).
     They have also got CHQ to work on Delphi, which has to be slower
than the net. However, on Delphi, I think they could only play at 50%
speed.
     By the way, the NETWORK.OVL file is available on wuarchive as
chqnetov.zip. If any of you want to help us to get this to work, drop
me a line.  ([e-mail])

                         Rainbow Warrior

                              (The Eternal Optimist)

                 ([e-mail])   Mike Sanches

-------------------------------

Date: Fri, 2 Jul 93 17:08:16 CDT
From: Johnny Stephens <[e-mail]>
To: Multiple recipients of list <[e-mail]>
Subject: Dialer Source Files

Thanks to all who responded to my first post.  I was able to grab the
dialer1.6.3.shar off cactus.org, but my VAX host apparently doesn't know
how to unpack .shar files. (Or, *maybe* it's ME!)  It can handle .Z
files ok, though.

Could some kind soul send me the source in .Z, .ZIP or vanilla ASCII
format?  Thanks in advance.

[e-mail]
        -OR-
ICJPS@ASUACAD

--
Johnny

---------------------------------------------------------------------------
Johnny P. Stephens           | Sig file upgrade on backorder.  Will be
Distance Learning Technology | here "any day now."
Arizona State University     |  Opinions expressed are mine.
----------------------------------------------------------------------------

Date: Fri, 2 Jul 93 11:16:25 CDT
From: Johnny Stephens <[e-mail]>
To: Multiple recipients of list <[e-mail]>
Subject: SVGA Air Warriors

Hello!  I'm a newbie here.  I'm a former SVGA Air Warrior user, but don't
use Genie anymore.

I'm perusing the mail archive from this list to find out what I need, but
would appreciate hearing from anyone who has advice on how to proceed.

Other multi-player games I have:  WORLD CIRCUIT   FALCON 3.0


Johnny Stephens
Arizona State University
[phone] Work
[phone] Home

---------------------------------------------------------------------------
Johnny P. Stephens           | Sig file upgrade on backorder.  Will be
Distance Learning Technology | here "any day now."
Arizona State University     |  Opinions expressed are mine.
----------------------------------------------------------------------------

Date: Sun, 4 Jul 93 04:17:24 CDT
From: [e-mail]
To: Multiple recipients of list <[e-mail]>
Subject: Playing over the net

I have been a member of IHHD for a couple of months but I
havn't tried it yet. But I have a question to you who is using
it frequently, how good is it? Is it as fantastic as it sounds
or...?

Patrik J.

---------------------------

Date: Sun, 4 Jul 93 00:17:54 CDT
From: "Randy W. Stoller" <[e-mail]>
To: Multiple recipients of list <[e-mail]>
Subject: Line Wars

I just uploaded a game called Line Wars to the incoming directory of
cactus.org.  It's a pretty fun space combat game that can be played over
the modem.  Hopefully it will be moved into the multi-player directory soon.

[e-mail]

---------------------------------

Date: Sun, 4 Jul 93 00:12:56 CDT
From: [e-mail] (michael sanches)
To: Multiple recipients of list <[e-mail]>
Subject: P.S.

Hi Folks (again),

     By the way, I got the OPERATION COM-BAT game at Wal-Mart for
about $12.

            ([e-mail])     Rainbow Warrior

-------------------------------

Date: Sun, 4 Jul 93 00:05:55 CDT
From: [e-mail] (michael sanches)
To: Multiple recipients of list <[e-mail]>
Subject: Opponents wanted

Hi folks,

     I am still looking for people to see if we can get Command HQ to
work. I feel we are getting close!

     I am also looking for an opponent to see if we can get OPERATION
COM-BAT, by Merit Software, to work. It is a turn-based game with a
timer and each unit moves once. It looks like fun, though I haven't played
it. It looks like you could easily finish a game in less than an hour.

            ([e-mail])     Rainbow Warrior

---------------------------------

Date: Tue, 6 Jul 93 18:12:45 CDT
From: Johnny Stephens <[e-mail]>
To: Multiple recipients of list <[e-mail]>
Subject: Dialer source code

Profuse apologies for the repost, but here goes:

My local host is a VMS machine, not Unix.  I don't know of a way to get it to
unpack the .shar file of the source.

If someone could point me to a utility, or mail me the code in .Z, .ZIP, or
plain ole' ASCII, I'd be grateful.

Hope to be able to try linking up with Air Warrior soon..

Thanks!
--
Johnny

-----------------------------

Date: Wed, 7 Jul 93 01:32:47 CDT
From: [e-mail] (Jim Knutson)
To: Multiple recipients of list <[e-mail]>
Subject: Re: Dialer source code

A .shar file is a self extracting shell script (DCL for you VMS types).
If you don't have a Bourne shell to run it, then extract the files
using your favorite editor.

The file starts with the string:
sed 's/^@//' > "filename" <<'@//E*O*F filename//'

which says put all the text that follows into the file "filename".
It also removes any leading at signs and it stops including lines
when it finds a line with just the text '@//E*O*F filename//'.

Jim

---------------------------

Date: Mon, 28 Jun 93 22:54:32 CDT
From: Kris Ong <[e-mail]>
To: Multiple recipients of list <[e-mail]>
Subject: Super Tetris

Has anyone tried Super tetris with dialer. If anyone wants to try...mail
me.

--
[e-mail]           An eye for an eye will make the
[e-mail]               whole world blind.
Prodigy: GRTV13B                                 -MLK Jr.

----------------------------

Date: Fri, 25 Jun 93 16:49:35 CDT
From: [e-mail] (Jeff Hanna)
To: Multiple recipients of list <[e-mail]>
Subject: Almost there....

Many thanks to those of you who helped me get tcpdialer.c to compile. I just
successfully did it (and the crowd goes wild).

Is showlog.c necessary for IHHD to work?  Guess what won't compile (and the
crowd flogs the poster).

Here are the results.  Looks to me to be the same type of problem I had with
tcpdialer.c

$ gcc showlog.c
showlog.c: In function main:
showlog.c:31: `time_t' undelcared (first use this function)
showlog.c:31: (Each undelcared identifier is reported only once
showlog.c:31: for each function it appears in.)
showlog.c:31: parse error before `('
$

Jeff

-------------------------------

Date: Wed, 14 Jul 93 09:08:21 CDT
From: [e-mail] (Greg Cisko)
To: Multiple recipients of list <[e-mail]>
Subject: World Circuit attempt!!!!

PC config
---------
Local:                    Remote:
Goldstar 386/sx W/387                   IBM Model 60 / 286
1MB TrueColor SVGA card                 DOS 6.0
MSDOS 5.0 /Stacker 3.0
ViVa 14400i Fax/modem
QuickLinkII
19200 8/n/1                19200 8/n/1

Internet Hosts
--------------
d0tokensun.fnal.gov            cunixb.cc.columbia.edu
SUN SPARCstation IPX                    SUN 490
SunOS 4.1.3                SunOS 4.1.2 or 4.1.3
Cisco modem server            ?


Test Date Friday June 4, 1993
Test Date Friday July 9, 1999
Testers :

Local: Greg Cisko    Remote: Jonathan David Kemp

Program Tested: World Circuit V1.05

Dialer program used:

TCPCALL/TCPANSWER 6/4/93
DIALER            7/9/93
------------------------------------------------------------------------------

World Circuit had been VERY quick to connect and (SYNC connections) using
the "normal" modem connection. I was very hopefull that this would work. I
really thought the only problem would be a very poor framerate. I was right
on one point. Once we went thru the link menu to link. We recieved the "link
established" ICON very quickly. So far so good. The next step is to transfer
data and SYNC both machines. The program went to the data transfer window
and stopped! This transfer usually takes seconds not minutes. After a few
minutes the program reported the connection was lost & exited the link
routines. At least the computer didn't lock up (like it did for falcon!)
So this is my report. I'm not sure what the next step should be. Jonathan
mentioned trying dialer instead of tcpdialer. Maybe we will....

And we did on July 9th. Basicly, the same results. It doesn't seem that
IHHD is a possibility for WC/F1GP. Too bad...

Greg Cisko

----------------------------------

Date: Wed, 14 Jul 93 17:39:35 CDT
From: [e-mail] (Jim Knutson)
To: Multiple recipients of list <[e-mail]>
Subject: Info on some modem games

This appeared in a recent USENET article.  I thought it might be of interest.

------- Begin included article ------

From: [e-mail] (Andy Sulon)
Newsgroups: comp.sys.ibm.pc.games.strategic
Subject: Re: Alleged Modem Play
Keywords: modem, ripoffs
Date: 7 Jul 93 17:37:55 GMT

One thing you definitly want to look into is getting the updates for
all the programs. I have succesfully played Perfect General, Conquered
Kingdoms, Empire Deluxe, and Global Conquest along with others that you
didn't mention. There are updates for ALL these games. Some updates
are specifically for modem connection problems. In fact, all the games
I mentioned above have fixes to the modem connection SW in the update.

I agree that getting these to work is quite a chore, but it is possible.
And definitly worth the effort.

Here is a list of what I believe to be the latest version and
where I got it from.

     Conquered Kingdoms        v1.1        Comes with Scenario Disk
     Empire Deluxe             v3.2        FTP (forget where)
     Global Conquest           v2.0        MPS BBS (available FTP too)
     Perfect General           v1.2        Comes with Scenario Disk

QQP allowed me to upload the updates to DELPHI so there should be
no problem with uploading to some FTP site on the NET. However, my
NET upload record is 0-2 so I'd be happy to e-mail them out to
someone who knows what the hell their doing.

AES

------ End of included article ------

--------------------------------------

Date: Thu, 15 Jul 93 10:27:28 CDT
From: [e-mail] (Jim Knutson)
To: Multiple recipients of list <[e-mail]>
Subject: IHHD and Air Warrior

Just wanted to let everyone know that IHHD appears to be working fairly
well for Air Warrior.  There are several of us using it fairly regularly
to play Air Warrior.  You will probably not see many more Air Warrior
test results due to this.

Jim

----------------------------------

Date: Thu, 15 Jul 93 10:38:27 CDT
From: [e-mail] (Jim Knutson)
To: Multiple recipients of list <[e-mail]>
Subject: What's next?

Test results on new games have slowed down a bit, so I assume that
everyone who wants to contribute has contributed what they can.  I
think we have shown that the concept works reasonably well, but there
are some games that just don't work well across "long delay" links.

The next thing to determine is what kind of features should this setup
have.  Here's my view on the subject.  Note, this is without ever
having used Compuserve, GEnie, etc. so I don't know how it compares to
those types of services.

1. There should be some automated way to determine which dialer is
   usable from your site.

2. There should be some way for novice users to determine how good a
   connection it is.

3. There should be some form of a discussion area where players can
   meet to discuss their connections, etc.

There are probably others.  What do the rest of you think?

I would rather not reinvent the world if I can help it, so I was
thinking of using IRC to handle the discussion areas.  Anyone have any
thoughts good or bad about this?

Jim Knutson
[e-mail]
cs.utexas.edu!milano!knutson
Wk: [phone]

--------------------------------------

Date: Thu, 15 Jul 93 10:46:55 CDT
From: [e-mail] (William D. Street)
To: Multiple recipients of list <[e-mail]>
Subject: Spectre

I saw the report for Spectre in the archives.....

anyone else ever try it and have any luck with it?

Thanks,
Bill

----------------------------------

Date: Thu, 15 Jul 93 11:02:35 CDT
From: "I'll see you on the dark side of the moon" <[e-mail]>
To: Multiple recipients of list <[e-mail]>
Subject: tests...

Regarding tests, etc...

#1 - Most of the time it seems the tcp dialer is easier to run because it
is a stateful protocol...unlike udp/datagram. I would suggest it default
to tcp, unless otherwise specified.

#2 - I think ping or traceroute is pretty straight forward to use, maybe
write a shell script to ask for a hostname and ping it and give
results..try 1024 byte packets possibly, (size 1016.) traceroute wold be
optimal for seeing routes/hops etc.

#3 - IRC sounds great to me, there could be a #ihhd channel, one could
even write a bot to handle competitions and connecting..reminders sent out
to players at certain times, etc. (Albeit a little complicated..maybe
better to write a perl or C bot) Also, if they were to play Perfect
General they woldnt even have to leave IRC to play...

-Chris
 ---
[e-mail]

---------------------------------

Date: Thu, 15 Jul 93 23:05:48 CDT
From: [e-mail] (Michael Fulbright)
To: Multiple recipients of list <[e-mail]>
Subject: Command HQ Success!

Test Date:    7/15/93

PC config
---------
Local:                    Remote:
80386-33                80386-33
Boca SVGA (ET4000)            Boca SVGA (ET4000)
MSDOS 5.0                DOS 5.0
Practical Periphs PM14400FXMT        Microcom AV2400c (no compr/err corr.)
Kermit 3.11                Telix
1200/1200 (serial/connect) 8/n/1    1200/1200 8/n/1

Internet Hosts
--------------
astro.as.arizona.edu            skaro.as.arizona.edu
Sun 690(?) server            Decstation 3100
SunOS 4.1.2                Ultrix 4.2
Dialin thru annex            Dialin thru annex


Ping Test
---------
----raz.csc.ncsu.edu PING Statistics----
113 packets transmitted, 112 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 156/162/218

NOTE - raz.csc.ncsu.edu is where the fellow running on skaro is
really located. We couldnt get a connected to work to his machine
(tcpcall got a core dump, tcpdialer never picked up the phone). So
he rlogins from raz to skaro. I log onto astro and do a tcpanswer.
He does a tcpcall on skaro and it works. If I try to call skaro from
astro it never works. No core dump, no nothing. It just sits there.
The ping times from skaro to astro are:

35 packets transmitted, 35 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 0/0/3

So you can see these machines are virtually directly connected.


PC/Internet Host Kermit File Transfer
-------------------------------------
I don't have precise #'s, but something in the 180cps range using
extended packets.

PC/PC Kermit File Transfer
--------------------------
We havent tried this yet.

Software Test
-------------
Command HQ v1.97 -

 This is a nasty beast! No configuration possible except comm port,
no chat mode prior to making the connection. It allows modem
connections, where the program dials the phone and connects to the
other machine. This doesnt appear to be the way to use Command HQ with
IHHD.

 Alternatively you can do a 'direct serial' connection. However, when
you do this the program drops and raises DTR - causing the modem to
lose it connection. However, the S21 register on most modems
apparently can be used to disable this side effect. In my modem manual
(the Practical Peripherals) S21 is lister as a reserved register, but
in my friends modem manual it  basically says set S21=0 and the modem
will ignore any changes in DTR.

NOTE- YOU MUST USE 1200 BAUD either way, this is hard coded.

Ok, now things get murkier! We were able to use the direct connect
option without losing carrier. Both modems TX lights were lit solidly,
as both machines were sending CNTL-@'s to each other. But neither of
our RX lights were on. The logfile created by tcpdialer showed that
characters were indeed being sent from our machines.

So we tried again, except I stayed in Kermit with 'set debug session'
on, so control characters are printed out when in connect mode. My
friend started up the direct connect and I started to receive
characters! Weird. So it dawns on me that Command HQ must not use
hardware flow control during a direct connect. So I told my modem to
not use any flow control, and then we tried connected. This time I did
receive and transmit characters (both lights blinked). Unfortunately
my friend was apparently unable to disable flow control on his modem,
as he only sent characters.

So he dug out a breakout box and tied CTS and RTS together. We tried
to connect again and voila! It worked. We then played a game for about
an hour with no problems. The chat mode seemed to work, but we didnt
really press our luck.

So, the recipe to get command hq to work:

1) Set your modem so it ignores transitions in DTR - the default seems
to be to hang up. On our two modems the command was 'ATS21=0', but
check your manual. My manual says S21 is reserved, but it seems to
work anyway.

2) Set your modem to ignore handshaking completely. No XON/XOFF. No
RTS/CTS. On my modem (the Practical Periphs) the command was AT&K0.
Otherwise you'll need to tell the modem to RTS/CTR and then rig things
up to tie RTS to CTS, otherwise your modem wont pass characters
through to command hq.

3) Make a 1200,8,n,1 connection using your favorite comm program. Be
sure your comm program doesnt initialize your modem and negate steps 1
and 2 above.

4) Run command hq and then select human player, direct serial and then
whatever com port your modem is on.


If the DTR light blinks and you immediately lose carrier then you
werent successful on step 1 above. If you have an internal modem and
you cant monitor DTR, its a good bet you failed on step 1 if you lose
carrier as well. If you get to the point where it says 'Testing
Connection' and you havent lost carrier then you should see both your
transmit and receive lights on your modem flash. If only transmit
flashes then you probably werent successful with step 2. It usually on
takes 10-15 seconds to get the 'Connected' message.


Hope this helps everyone!


--------------------------------------

Date: Thu, 15 Jul 93 23:08:52 CDT
From: [e-mail] (Michael Fulbright)
To: Multiple recipients of list <[e-mail]>
Subject: Perfect General Success!

Test Date:    7/13/93

PC config
---------
Local:                    Remote:
80386-33                80386-33
Boca SVGA (ET4000)            Boca SVGA (ET4000)
MSDOS 5.0                DOS 5.0
Practical Periphs PM14400FXMT        Microcom AV2400c (no compr/err corr.)
Kermit 3.11                Telix
2400/2400 (serial/connect) 8/n/1    2400/2400 8/n/1

Internet Hosts
--------------
astro.as.arizona.edu            skaro.as.arizona.edu
Sun 690(?) server            Decstation 3100
SunOS 4.1.2                Ultrix 4.2
Dialin thru annex            Dialin thru annex


Ping Test
---------
----raz.csc.ncsu.edu PING Statistics----
113 packets transmitted, 112 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 156/162/218

NOTE - raz.csc.ncsu.edu is where the fellow running on skaro is
really located. We couldnt get a connected to work to his machine
(tcpcall got a core dump, tcpdialer never picked up the phone). So
he rlogins from raz to skaro. I log onto astro and do a tcpanswer.
He does a tcpcall on skaro and it works. If I try to call skaro from
astro it never works. No core dump, no nothing. It just sits there.
The ping times from skaro to astro are:

35 packets transmitted, 35 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 0/0/3

So you can see these machines are virtually directly connected.


PC/Internet Host Kermit File Transfer
-------------------------------------
I don't have precise #'s, but something in the 180cps range using
extended packets.

PC/PC Kermit File Transfer
--------------------------
We havent tried this yet.

Software Test
-------------
Perfect General:

 We are not currently using the latest version (1.2 I think). The
program never reports the version #, its just the original version.
We met after doing a tcpcall/tcpanswer and chatted in the chat mode
of Perfect General. We then agreed who would be the primary player.
The two computers synchronized with no troubles and we played
approximately 2 1/2 hours with no glitches. The game was fairly
responsive to commands. We popped up the chat window several times
while playing with no problems. We were also able to save the game
successfully and restart. Overall, Perfect General seems to work
without any problems!


-------------------------------

Date: Mon, 26 Jul 93 17:05:07 CDT
From: Johnny Stephens <[e-mail]>
To: Multiple recipients of list <[e-mail]>
Subject: dialer compile problems

At the risk of exposing my naivete' regarding C, I'm having problems
compiling the dialer code:

$ make
        gcc -g  showlog.c -o showlog
showlog.c: In function `main':
showlog.c:31: `time_t' undeclared (first use this function)
showlog.c:31: (Each undeclared identifier is reported only once
showlog.c:31: for each function it appears in.)
showlog.c:31: parse error before `)'
*** Error code 1

Stop.


This system is running System V/88 on a Sun SPARCcenter 2000.  Anyone else
run into this?  Is it a simple fix?

I don't have easy access to the manuals for this compiler....can anyone
help?

Thanks in advance!
Johnny

-----------------------------------

Date: Mon, 26 Jul 93 17:21:18 CDT
From: [e-mail] (Jim Knutson)
To: Multiple recipients of list <[e-mail]>
Subject: Re: dialer compile problems

I wonder what happened to the standard include files.  Anyway,
you can include the following line at the top of the file:

typedef long time_t;

Jim Knutson                                                | |
[e-mail]                                         --=oOo=--
cs.utexas.edu!milano!knutson                               +
Wk: [phone]                                      Check Six!

------------------------------------

Date: Tue, 27 Jul 93 08:12:43 CDT
From: "Mach, Rick" <[e-mail]>
To: Multiple recipients of list <[e-mail]>
Subject: RE: dialer compile problems

I have never compiled the code but I do know C.  time_t is a typedefed
variable type.  It looks like you are missing the define in one of the
header files.  You could search the header files to see which one contains a
typedef ??? time_t.  In ANSI C, it is located time.h.  You could add it to
the c file if you cannot find the include file.  Something like

typedef long time_t

should probably work.

Rick

PS:  Does anyone else have a suggestion?
 ---------
From: ihhd
To: Multiple recipients of list
Subject: dialer compile problems
Date: Monday, July 26, 1993 5:08PM

At the risk of exposing my naivete' regarding C, I'm having problems
compiling the dialer code:

$ make
        gcc -g  showlog.c -o showlog
showlog.c: In function `main':
showlog.c:31: `time_t' undeclared (first use this function)
showlog.c:31: (Each undeclared identifier is reported only once
showlog.c:31: for each function it appears in.)
showlog.c:31: parse error before `)'
*** Error code 1

Stop.


This system is running System V/88 on a Sun SPARCcenter 2000.  Anyone else
run into this?  Is it a simple fix?

I don't have easy access to the manuals for this compiler....can anyone
help?

Thanks in advance!
Johnny

--------------------------------

Date: Fri, 30 Jul 93 13:00:45 CDT
From: [e-mail] (Jim Knutson)
To: Multiple recipients of list <[e-mail]>
Subject: Getting off the list

Please stop sending unsubscribe messages to the mailing list.

If you want to get off the list, send email to [e-mail]
with the following text:

unsubscribe ihhd

Jim Knutson                                                | |
[e-mail]                                         --=oOo=--
cs.utexas.edu!milano!knutson                               +
Wk: [phone]                                      Check Six!

----------------------------

Date: Fri, 30 Jul 93 16:29:15 CDT
From: Jeff Beadles <[e-mail]>
To: Multiple recipients of list <[e-mail]>
Subject: Problems with dialer, et al...

Well, I finally broke down and decided to port the ihdd stuff to BSDI.
(386 based BSD unix.)

After wading thru the terminal control stuff, and successfully getting it to
build, I've ran up against what I think is a wall.

It appears that dialer sends data out over the network in host-specific byte
order.  (endian-ness).  I attempted to test it from a Sun 3/60 (Motorola 68xxx
processor) and my BSDI box with a 80386.  After expermentation, I used the
-l logfile option, and looked at the data.  I saw:

od -c of 386.out file:
0000000    O 213   Y   , 021   u  \0  \0 001  \0  \0  \0   Z   O 213   Y
0000020    ,   ?   1 003  \0 001  \0  \0  \0   Z   O 213   Y   ,   ; 363
0000040  005  \0 001  \0  \0  \0   Z   O 213   Y   ,   / 264  \b  \0 001
0000060   \0  \0  \0   Z   O 213   Y   ,   ?   ] 013  \0 001  \0  \0  \0
0000100    Z   O 213   Y   ,   q 356  \r  \0 001  \0  \0  \0   Z   Q 213
0000120    Y   ,   ] 242 007  \0 001  \0  \0  \0 003   Q 213   Y   , 034
0000140  020  \n  \0 001  \0  \0  \0 003   Q 213   Y   , 374 025  \f  \0
0000160  001  \0  \0  \0 003
0000165

And, of the 68000.in file:
0000000    ,   Y 213   O  \0 002 255 345  \0  \0  \0 001   Z   ,   Y 213
0000020    O  \0 005   m 003  \0  \0  \0 001   Z   ,   Y 213   O  \0  \b
0000040    ,   $  \0  \0  \0 001   Z   ,   Y 213   O  \0 013   9   g  \0
0000060   \0  \0 001   Z   ,   Y 213   O  \0  \r   \   I  \0  \0  \0 001
0000100    Z   ,   Y 213   P  \0  \0 331   &  \0  \0  \0 001   Z   ,   Y
0000120  213   Q  \0  \t 262 310  \0  \0  \0 001 003   ,   Y 213   Q  \0
0000140   \f   # 307  \0  \0  \0 001 003   ,   Y 213   Q  \0 016   F 246
0000160   \0  \0  \0 001 003
0000165

Has anyone successfully run this program from different architecture hosts?
It *really* looks like a byte ordering problem.

On another note, I'd be interested in trying this with SVGA AW.  Anyone
interested?  (I'm in the PST timezone.)  Drop me a note if so.

Also attached are the diffs that I had to make for BSDI compilation.
I'm not 100% sure that they are correct, as with the byte ordering problem
I couldn't test things right.  (I could type on the BSDI box and see it on
the Sun, but not vice versa.)

Suggestions/comments anyone?  I think that the "right" thing to do is to send
out all data in network byte order, let the client decode it for their
architecture.

    -Jeff
--
Jeff Beadles        [e-mail]


The Makefile needed to have explicit dependencies on the targets.

% diff Makefile.orig  Makefile
14a15,21
> dialer: dialer.c
>       $(CC) $(CFLAGS) -o dialer dialer.c
> tcpdialer: tcpdialer.c
>       $(CC) $(CFLAGS) -o tcpdialer tcpdialer.c
> showlog: showlog.c
>       $(CC) $(CFLAGS) -o showlog showlog.c
>

dialer & tcpdialer had the same changes.
Changed [sg]tty to the proper ioctls.

diff tcpdialer.c.orig  tcpdialer.c
346a347,349
> #ifdef bsdi
>       ioctl(0, TIOCGETP, &saved_tty);
> # else
347a351
> #endif
351a356,358
> #ifdef bsdi
>       ioctl(0, TIOCSETP, &saved_tty);
> #else
352a360
> #endif
358a367,371
> #ifdef bsdi
>       ioctl(0, TIOCGETP, &tty);
>       tty.sg_flags |= RAW;
>       ioctl(0, TIOCSETP, &tty);
> #else
361a375
> #endif
367a382,386
> #ifdef bsdi
>       ioctl(0, TIOCGETP, &tty);
>       tty.sg_flags &= ~RAW;
>       ioctl(0, TIOCSETP, &tty);
> # else
370a390
> #endif
378a399,401
> #ifdef bsdi
>     ioctl(0, TIOCGETP, &tty);
> # else
379a403,404
> #endif
>
385a411,413
> #ifdef bsdi
>       ioctl(0, TIOCSETP, &tty);
> # else
386a415
> #endif

-----------------------------------

Date: Fri, 30 Jul 93 17:15:41 CDT
From: [e-mail] (Jim Knutson)
To: Multiple recipients of list <[e-mail]>
Subject: Re: Problems with dialer, et al...

> It appears that dialer sends data out over the network in host-specific byte
> order.  (endian-ness).  I attempted to test it from a Sun 3/60 (Motorola 68xxx
> processor) and my BSDI box with a 80386.  After expermentation, I used the
> -l logfile option, and looked at the data.  I saw:
>
> od -c of 386.out file:
> 0000000    O 213   Y   , 021   u  \0  \0 001  \0  \0  \0   Z   O 213   Y
>
> And, of the 68000.in file:
> 0000000    ,   Y 213   O  \0 002 255 345  \0  \0  \0 001   Z   ,   Y 213

You should use the showlog program to print the log files.  The log
files contain not only the data pumped through the dialer programs, but
also time stamps.  The time stamps are written to the log in binary form
and are in a host dependent format.  The data that dialer pumps is
strictly a sequential stream of bytes without any specific order.

> Has anyone successfully run this program from different architecture hosts?
> It *really* looks like a byte ordering problem.

It has been run on a variety of hosts (Sun, NeXT, probably some others).

> On another note, I'd be interested in trying this with SVGA AW.  Anyone
> interested?  (I'm in the PST timezone.)  Drop me a note if so.

I'll fly with you.  Drop me a note to schedule an evening.

> Also attached are the diffs that I had to make for BSDI compilation.
> I'm not 100% sure that they are correct, as with the byte ordering problem
> I couldn't test things right.  (I could type on the BSDI box and see it on
> the Sun, but not vice versa.)

Not sure why it only works in one direction.  I do know that you need
to specify the remote host on both sides.  E.g.:

sun> dialer bsdi.host.com

and

bsdi> dialer sun.host.com


You might want to start with tcpdialer -answer and tcpdialer -call
remotehost to verify that you have a bidirectional stream connection
that works.  It uses tcp instead of udp, but it might help your
diagnostics.

> Suggestions/comments anyone?  I think that the "right" thing to do is to send
> out all data in network byte order, let the client decode it for their
> architecture.

Can't as there's no byte groupings to determine the order of.  Only
the log files will be host specific and I don't know if it's worth
doing network byte ordering for the time stamps in the log files.
What does everyone think?

By the way, thanks for the BSDI updates.  I'll encorporate them into
the code and put out another release soon.

Jim Knutson                                                | |
[e-mail]                                         --=oOo=--
cs.utexas.edu!milano!knutson                               +
Wk: [phone]                                      Check Six!

------------------------------------

Date: Sat, 31 Jul 93 09:44:48 CDT
From: [e-mail] (Timo Hakulinen)
To: Multiple recipients of list <[e-mail]>
Subject: patch to tcpdialer.c

Removing one leftover line which breaks up in AIX 3.1.  How come nobody
else has noticed this?  I'd expect it to cause a core dump in most systems.

Timo

*** tcpdialer.c.org    Wed Jun 30 17:27:11 1993
--- tcpdialer.c    Thu Jul  1 19:43:21 1993
***************
*** 198,204 ****
          while (1) {
              printf("Ringing %s...", remotehost);
              fflush(stdout);
-             bcopy(name,saddr,sizeof(name));
              errcode = connect(sock, (struct sockaddr*)&name,
                        sizeof name);
              if (errcode == -1) {
--- 198,203 ----

----------------------------

Date: Sat, 31 Jul 93 13:58:25 CDT
From: Jeff Beadles <[e-mail]>
To: Multiple recipients of list <[e-mail]>
Subject: Re: Problems with dialer, et al...

> Jim Knutson <[e-mail]> wrote:
>> Jeff Beadles  <[e-mail]> wrote:
>> It appears that dialer sends data out over the network in host-specific byte
>> order.  (endian-ness).  I attempted to test it from a Sun 3/60 (Motorola 68xxx
>> processor) and my BSDI box with a 80386.  After expermentation, I used the
>> -l logfile option, and looked at the data.  I saw:
>>
>> od -c of 386.out file:
>> 0000000    O 213   Y   , 021   u  \0  \0 001  \0  \0  \0   Z   O 213   Y
>>
>> And, of the 68000.in file:
>> 0000000    ,   Y 213   O  \0 002 255 345  \0  \0  \0 001   Z   ,   Y 213
>
>You should use the showlog program to print the log files.  The log
>files contain not only the data pumped through the dialer programs, but
>also time stamps.  The time stamps are written to the log in binary form
>and are in a host dependent format.  The data that dialer pumps is
>strictly a sequential stream of bytes without any specific order.

Ahhhh!  That makes sense.  The clocks between the two hosts are synced
to in the ms range, so that explains things being identical except for byte
ordering.

>> Also attached are the diffs that I had to make for BSDI compilation.
>> I'm not 100% sure that they are correct, as with the byte ordering problem
>> I couldn't test things right.  (I could type on the BSDI box and see it on
>> the Sun, but not vice versa.)
>
>Not sure why it only works in one direction.  I do know that you need
>to specify the remote host on both sides.  E.g.:
>sun> dialer bsdi.host.com
>bsdi> dialer sun.host.com
>
>You might want to start with tcpdialer -answer and tcpdialer -call
>remotehost to verify that you have a bidirectional stream connection
>that works.  It uses tcp instead of udp, but it might help your
>diagnostics.

After further investigation, I have found the following;

tcpdialer works fine in both directions.  When running dialer,
the BSDI box can send to the Sun, but when the Sun sends to the
BSDI box, it receives ICMP port unreachable. (The wonders of Etherfind! :-)
It appears that the BSDI box isn't listening on the socket.  I'm going
to dig into this further soon.  (Has anyone else seen anything like this?)

>> Suggestions/comments anyone?  I think that the "right" thing to do is to send
>> out all data in network byte order, let the client decode it for their
>> architecture.
>
>Can't as there's no byte groupings to determine the order of.  Only
>the log files will be host specific and I don't know if it's worth
>doing network byte ordering for the time stamps in the log files.
>What does everyone think?

It's not worth it!  Please forget that I even mentioned it. :-)

>By the way, thanks for the BSDI updates.  I'll encorporate them into
>the code and put out another release soon.

Sure!  It's the only machine here with spare serial ports.
(I'll be running ihhd via a PC that is plugged directly into a
serial port on an internet-connected host.)

Later, and thanks for the help,
    -Jeff
--
Jeff Beadles       [e-mail]

---------------------------------

Date: Mon, 2 Aug 93 16:06:56 CDT
From: [e-mail] (Jim Knutson)
To: Multiple recipients of list <[e-mail]>
Subject: fly8 simulator on cactus.org

I just added the Fly8 flight simulator to the archives on cactus.org.

It's a wire frame graphics jet dogfight flight simulator that supports
multiplayer capabilities.  I haven't tried to use the multi-player
stuff yet though.  It requires VGA, 386DX recommended and supports the
ET4000 video cards directly.

You can find it on cactus.org in:

/pub/IHHD/multi-player/fly8100d.zip    Dos executable and docs.
/pub/IHHD/multi-player/fly8100s.zip    Source for DOS, Amiga, & Sun.

Jim Knutson                                                | |
[e-mail]                                         --=oOo=--
cs.utexas.edu!milano!knutson                               +
Wk: [phone]                                      Check Six!

-------------------------------

Date: Wed, 4 Aug 93 11:33:06 CDT
From: [e-mail] (Gavin Adams)
To: Multiple recipients of list <[e-mail]>
Subject: SunOS Version of TCP Dialer

I'm having a bear of time getting enough disk space on my Sun to install
gcc.  Since the make file for tcpdialer seems to require this, I was
wondering if anyone has a compiled version of tcp dialer for SunOS 4.1.3???

If I do get it, I'm looking for some Air Warrior pilots to fly against.

-----------------------------------------------------------------------
Gavin "Boo Boo" Adams                           Visualize Whirled Peas!
Digital Equipment Corporation
[e-mail]
now appearing at...
Los Alamos National Laboratory
[e-mail]

-----------------------------------

Date: Wed, 4 Aug 93 13:57:12 CDT
From: [e-mail] (Gavin Adams)
To: Multiple recipients of list <[e-mail]>
Subject: I got it! No mora mail! Please! :)

Thanks to Greg, Mark, Bob, and Mike.  CC did indeed work fine, and I'm not
going to tell anyone that I write network software for a living. :)

Just need to install a modem on a local terminal server and I'm off to the
races (or skies)!

-----------------------------------------------------------------------
Gavin "Boo Boo" Adams                           Visualize Whirled Peas!
Digital Equipment Corporation
[e-mail]
now appearing at...
Los Alamos National Laboratory
[e-mail]

-------------------------------------

Date: Thu, 5 Aug 93 12:35:29 CDT
From: [e-mail] (Jim Knutson)
To: Multiple recipients of list <[e-mail]>
Subject: Re: SunOS Version of TCP Dialer

> I'm having a bear of time getting enough disk space on my Sun to install
> gcc.  Since the make file for tcpdialer seems to require this, I was
> wondering if anyone has a compiled version of tcp dialer for SunOS 4.1.3???

It doesn't require gcc.  Just change the CC=gcc to CC=cc.

> If I do get it, I'm looking for some Air Warrior pilots to fly against.

I'll fly against you.  Send me email to arrange a time.

Jim Knutson                                                | |
[e-mail]                                         --=oOo=--
cs.utexas.edu!milano!knutson                               +
Wk: [phone]                                      Check Six!

-------------------------------

Date: Thu, 5 Aug 93 16:06:48 CDT
From: [e-mail] (Gavin Adams)
To: Multiple recipients of list <[e-mail]>
Subject: IHHD Air Warrior Test Using Dialer

Sometimes it really amazes me that the Internet is so large and useful.  The
scary part is that I can't imagine life without some type of network access.
 Now only if the NSF will replace the NFSnet backbone with SONET or ATM
(maybe even HIPPI), and mandate all connections have at least T3 speed
lines... :)  Ok, ok, on to the test.

Air Warrior Test on 4-Aug-1993:

Bob Crane and myself flew for about an hour.  There were problems getting
talk to run, but after a few mail messages, I was able to connect via dialer
to his machine.

Once connected, Bob was able to issue the 'connect' message which my copy of
AW responded to.  There were only a couple of times where bad packets caused
problems, but beside that, we were able to fly.

Technical notes: I did some initial ping tests at 2135 PDT (0335Z), and out
of 20 packets, I was getting 81-110ms with ~97ms average response time.
This was spanning 1 time zone (Bob is in PDT), and at least 2 regional
carriers.  Bob, where exactly is wsu.edu?

Locally, I connected my PC to our lab's main terminal server at 9600 bps, no
correction or compression, and TELNETed into my Sun.  From there I ran the
dialer software.  Bob was also running at 9.6K, and AW was setup for a 9.6K
connection.

We did run into a few problems that might be related to too high of a baud
rate or pecularities (sorry, bad spelling day) in the AW software.  Our next
test will be at 2400 bps.

Overall, the connection was solid enough for Bob to give me a case of high
speed lead poisoning while I had great rear view of the hits. :)


--- Gavin (Visualize Whirled Peas!)

Gavin "Boo Boo" Adams
Digital Equipment Corporation            Los Alamos National Laboratory
[e-mail]              [e-mail]
505.662.2011                             505.667.5255

--------------------------------

Date: Fri, 6 Aug 93 01:11:33 CDT
From: Mutator <[e-mail]>
To: Multiple recipients of list <[e-mail]>
Subject: Seige

Every time I try to play Seige and Dogs of War with my brother using
tcpdialer, the game hangs after it transmits the scenario.  Is there
anyway to change this?
I apologize if I am sending this to the wrong place, but I am still new at
the stuff.

------------------------------------------------------------------------------
]  Mutator              ][ "The first one to die LOSES!"                     [
]  [e-mail] ][          Tug Benson, HOT SHOTS PART DEUX          [
-------------------------------------------------------------------------------

----------------------------------

Date: Fri, 6 Aug 93 10:37:19 CDT
From: Johnny Stephens <[e-mail]>
To: Multiple recipients of list <[e-mail]>
Subject: AW players

Well, I finally got dialer to compile on my machine.  Thanks to those who
helped me through this.

I'd be interested in testing it out some evening this weekend...if you're so
inclined, let me know.

--
Johnny

-----------------------------------

Date: Mon, 9 Aug 93 15:53:35 CDT
From: [e-mail] (Jim Knutson)
To: Multiple recipients of list <[e-mail]>
Subject: Re: Seige

There may be several reasons for hangs.  The most probable that I can
think of is using flow control.  Try turning it off on your modem and
see if that helps.  You can also try using dialer instead of
tcpdialer.

Jim

---------------------------------

Date: Mon, 9 Aug 93 19:46:41 CDT
From: [e-mail]
To: Multiple recipients of list <[e-mail]>
Subject: I need clear-cut step-by-step information

    I'm very new to the concept of playing certain games over the net.  I
need a text file telling me exactly what to do and how do it.  I downloaded the
dialer program from cactus.org.  But, unfortunately it's not compiled.  How do
I compile, what do I do with it once it's compiled, etc.?  I've also heard of
something called IUL? What is it, where do I get it, etc.  I'm quite confused.
I would appreciate it if someone could send me an information file (or tell me
what ftp site to get it from) explaining all that has to do with this concept.
Thank you for your time.  Please e-mail me as soon as possible.



                    [e-mail]

-------------------------------

Date: Mon, 9 Aug 93 21:26:27 CDT
From: Russell Webb <[e-mail]>
To: Multiple recipients of list <[e-mail]>
Subject: IHHD new user comments

Hello, I just joined the IHHD list and managed to get the tcpdialer
programs compiled on a Sun 1+.  It took two bits of fiddling:
1) the bcopy patch mentioned several days ago (I saw this in the
mail archive), and 2) the inet_ntoa call on line 179 of tcpdialer.c
code:

   len = sizeof(saddr);
   if (getpeername(msgsock, &saddr, &len) == 0) {
>       printf("\007answered call from %s\n",inet_ntoa(saddr.sin_addr));
   }

Header files and dbx tell me that sin_addr is a union that evaluates to
-2139448823 (or 2155518473?).  After removing this call, the progam no
longer dumps core and does echo text back and forth between the clients.
Is this a deficiency in the Sun's networking code and setup [likely]?

There seem to be lots of flight sim fans on the list, I gather from
reading through the archive.  Actually, I've been looking at the code
and list traffic to think about the forthcoming action game DOOM
from Id Software.  Some DOOM server effort was announced by Ron
Dippold on one of the comp.sys.ibm.pc.games.* groups.   Did any
list members try to contact Dippold to arrange a group effort?
It seems that there might be some duplication of work if the
IHHD core is basically suitable for the *4*-player hack that is
planned.
--
-Russell Webb
[e-mail]

-----------------------------------------------------------------------------